Multi-factor secure appliance decommissioning

ABSTRACT

A network-based appliance includes a mechanism to erase data on the appliance&#39;s local storage. The appliance&#39;s normal system reset operation is overridden to enable a local user to place the appliance into a safe mode during which remote erasure of the storage is permitted, provided that mode is entered within a first time period following initiation of a system reset. If the appliance is placed in the mode within the time period, it can then receive commands to wipe the local storage. Once the safe mode is entered by detecting one or more actions of a local user, preferably the appliance data itself is wiped by another person or entity that is remote from the device. Thus, physical (local) presence to the appliance is necessary to place the device in the safe mode, while non-physical (remote) presence with respect to the appliance enables actual wiping of the storage device.

BACKGROUND OF THE INVENTION

1. Technical Field

This disclosure relates generally to information security onnetwork-connected appliances.

2. Background of the Related Art

Network-connected, non-display devices (“appliances) are ubiquitous inmany computing environments.

For example, appliances built purposely for performing traditionalmiddleware service oriented architecture (SOA) functions are prevalentacross certain computer environments. SOA middleware appliances maysimplify, help secure or accelerate XML and Web services deploymentswhile extending an existing SOA infrastructure across an enterprise. Theutilization of middleware-purposed hardware and lightweight middlewarestacks can address the performance burden experienced by conventionalsoftware solutions. In addition, the appliance form-factor provides asecure, consumable packaging for implementing middleware SOA functions.One particular advantage that these types of devices provide is tooffload processing from back-end systems. To this end, it is well-knownto use such middleware devices to perform computationally-expensiveprocesses related to security.

Another common use for appliances is network security. For example,network intrusion prevention system (IPS) appliances are designed to sitat the entry points to an enterprise network to protectbusiness-critical assets, such as internal networks, servers, endpointsand applications, from malicious threats.

Other appliance-based solutions are common in cloud computeenvironments. Cloud compute resources are typically housed in largeserver farms that run networked applications, typically using avirtualized architecture wherein applications run inside virtualservers, or so-called “virtual machines” that are mapped onto physicalservers in a data center facility. Appliances are often used in thesetypes of environments to facilitate rapid adoption and deployment ofcloud-based offerings. Typically, the appliance is positioned directlybetween the business workloads that many organizations use and theunderlying cloud infrastructure and platform components.

While enterprise appliances of these types are quite varied and providenumerous advantages, they often need to be decommissioned for variousreasons, e.g. to enable servicing, because a lease on the deviceexpires, to facilitate an upgrade to new hardware, because the device issold, or the like. Appliances scheduled for decommissioning, however,often have sensitive data on them. Thus, for example, an applianceprovisioned to facilitate health care-related functions may storeHIPAA-regulated data. An appliance scheduled to be decommissioned may bestolen or otherwise accessed by unauthorized persons prior to itsdecommissioning, the sensitive data stored on the device is at risk. Oneobvious solution to this security concern is to wipe the contents of theappliance's drive. This is easier said than done. Because secureappliances of this type typically do not have keyboards, displays, CDdrives or often even USB-based ports, there is no convenient way to boota disk that might wipe the internal drive prior to or in associationwith the decommission. An alternative is to enable a remote wipe of theappliance, e.g., by a privileged remote administrator. That solution,however, raises another security risk, namely, how to prevent maliciousor accidental wipes (even from such a privileged administrator).

There remains a need to ensure protection of sensitive data on anappliance that is being decommissioned (or otherwise taken out ofservice) and, in particular, when the appliance is being managed from aremote location.

BRIEF SUMMARY

According to this disclosure, a network-based appliance includes amechanism to enable secure erasure of sensitive data on the appliance'slocal storage, e.g., prior to appliance decommissioning. In oneembodiment, the appliance's normal system reset operation is augmented(or overridden) to selectively enable a local user to place theappliance into an operating (or “safe”) mode during which remote erasureof the local storage is permitted, provided that mode is entered withina first time period following initiation of a system reset. If theappliance is placed in the mode within the first time period, it canthen receive appropriate commands to wipe the local storage. Thus, oncethe safe mode is entered by detecting one or more actions of a localuser, preferably the appliance data itself is wiped by another person orentity that is remote from the device. Typically, the person is a remoteprivileged administrator that is assumed to have the authority andcapability to formally “wipe” the appliance, but only while theappliance has been first placed into the safe mode. Thus, preferablyphysical (local) presence to the appliance is necessary to place thedevice in the safe mode, while non-physical (remote) presence withrespect to the appliance is the state during which actually wiping ofthe storage device occurs. This implements a “multi-factor”decommissioning operation, namely, a local operation (typically by afirst person or entity) to place the appliance in the proper safe mode,with a remote operation (typically by a second person or entity) thenbeing initiated to perform the erasure itself.

The foregoing has outlined some of the more pertinent features of thedisclosed subject matter. These features should be construed to bemerely illustrative. Many other beneficial results can be attained byapplying the disclosed subject matter in a different manner or bymodifying the subject matter as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary block diagram of a distributed dataprocessing environment in which exemplary aspects of the illustrativeembodiments may be implemented;

FIG. 2 is an exemplary block diagram of a data processing system inwhich exemplary aspects of the illustrative embodiments may beimplemented;

FIG. 3 illustrates an exemplary network-based secure appliance in whichthe disclosed subject matter may be implemented;

FIG. 4 illustrates a multi-stage operation by which the appliance may beplaced in a safe mode to permit remote wiping by augmenting a systemreset button function; and

FIG. 5 is a process flow illustrating a preferred multi-factor appliancedecommissioning function according to this disclosure.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

With reference now to the drawings and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments of the disclosure may beimplemented. It should be appreciated that FIGS. 1-2 are only exemplaryand are not intended to assert or imply any limitation with regard tothe environments in which aspects or embodiments of the disclosedsubject matter may be implemented. Many modifications to the depictedenvironments may be made without departing from the spirit and scope ofthe present invention.

Client-Server Technologies

With reference now to the drawings, FIG. 1 depicts a pictorialrepresentation of an exemplary distributed data processing system inwhich aspects of the illustrative embodiments may be implemented.Distributed data processing system 100 may include a network ofcomputers in which aspects of the illustrative embodiments may beimplemented. The distributed data processing system 100 contains atleast one network 102, which is the medium used to provide communicationlinks between various devices and computers connected together withindistributed data processing system 100. The network 102 may includeconnections, such as wire, wireless communication links, or fiber opticcables.

In the depicted example, server 104 and server 106 are connected tonetwork 102 along with storage unit 108. In addition, clients 110, 112,and 114 are also connected to network 102. These clients 110, 112, and114 may be, for example, personal computers, network computers, or thelike. In the depicted example, server 104 provides data, such as bootfiles, operating system images, and applications to the clients 110,112, and 114. Clients 110, 112, and 114 are clients to server 104 in thedepicted example. Distributed data processing system 100 may includeadditional servers, clients, and other devices not shown.

In the depicted example, distributed data processing system 100 is theInternet with network 102 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, the distributed data processing system 100 may also beimplemented to include a number of different types of networks, such asfor example, an intranet, a local area network (LAN), a wide areanetwork (WAN), or the like. As stated above, FIG. 1 is intended as anexample, not as an architectural limitation for different embodiments ofthe disclosed subject matter, and therefore, the particular elementsshown in FIG. 1 should not be considered limiting with regard to theenvironments in which the illustrative embodiments of the presentinvention may be implemented.

With reference now to FIG. 2, a block diagram of an exemplary dataprocessing system is shown in which aspects of the illustrativeembodiments may be implemented. Data processing system 200 is an exampleof a computer, such as client 110 in FIG. 1, in which computer usablecode or instructions implementing the processes for illustrativeembodiments of the disclosure may be located.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which illustrative embodiments may be implemented.Data processing system 200 is an example of a computer, such as server104 or client 110 in FIG. 1, in which computer-usable program code orinstructions implementing the processes may be located for theillustrative embodiments. In this illustrative example, data processingsystem 200 includes communications fabric 202, which providescommunications between processor unit 204, memory 206, persistentstorage 208, communications unit 210, input/output (I/O) unit 212, anddisplay 214.

Processor unit 204 serves to execute instructions for software that maybe loaded into memory 206. Processor unit 204 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 204 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 204 may be a symmetricmulti-processor (SMP) system containing multiple processors of the sametype.

Memory 206 and persistent storage 208 are examples of storage devices. Astorage device is any piece of hardware that is capable of storinginformation either on a temporary basis and/or a permanent basis. Memory206, in these examples, may be, for example, a random access memory orany other suitable volatile or non-volatile storage device. Persistentstorage 208 may take various forms depending on the particularimplementation. For example, persistent storage 208 may contain one ormore components or devices. For example, persistent storage 208 may be ahard drive, a flash memory, a rewritable optical disk, a rewritablemagnetic tape, or some combination of the above. The media used bypersistent storage 208 also may be removable. For example, a removablehard drive may be used for persistent storage 208.

Communications unit 210, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 210 is a network interface card. Communications unit210 may provide communications through the use of either or bothphysical and wireless communications links.

Input/output unit 212 allows for input and output of data with otherdevices that may be connected to data processing system 200. Forexample, input/output unit 212 may provide a connection for user inputthrough a keyboard and mouse. Further, input/output unit 212 may sendoutput to a printer. Display 214 provides a mechanism to displayinformation to a user.

Instructions for the operating system and applications or programs arelocated on persistent storage 208. These instructions may be loaded intomemory 206 for execution by processor unit 204. The processes of thedifferent embodiments may be performed by processor unit 204 usingcomputer implemented instructions, which may be located in a memory,such as memory 206. These instructions are referred to as program code,computer-usable program code, or computer-readable program code that maybe read and executed by a processor in processor unit 204. The programcode in the different embodiments may be embodied on different physicalor tangible computer-readable media, such as memory 206 or persistentstorage 208.

Program code 216 is located in a functional form on computer-readablemedia 218 that is selectively removable and may be loaded onto ortransferred to data processing system 200 for execution by processorunit 204. Program code 216 and computer-readable media 218 form computerprogram product 220 in these examples. In one example, computer-readablemedia 218 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 208 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 208. Ina tangible form, computer-readable media 218 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 200. The tangibleform of computer-readable media 218 is also referred to ascomputer-recordable storage media. In some instances,computer-recordable media 218 may not be removable.

Alternatively, program code 216 may be transferred to data processingsystem 200 from computer-readable media 218 through a communicationslink to communications unit 210 and/or through a connection toinput/output unit 212. The communications link and/or the connection maybe physical or wireless in the illustrative examples. Thecomputer-readable media also may take the form of non-tangible media,such as communications links or wireless transmissions containing theprogram code. The different components illustrated for data processingsystem 200 are not meant to provide architectural limitations to themanner in which different embodiments may be implemented. The differentillustrative embodiments may be implemented in a data processing systemincluding components in addition to or in place of those illustrated fordata processing system 200. Other components shown in FIG. 2 can bevaried from the illustrative examples shown. As one example, a storagedevice in data processing system 200 is any hardware apparatus that maystore data. Memory 206, persistent storage 208, and computer-readablemedia 218 are examples of storage devices in a tangible form.

In another example, a bus system may be used to implement communicationsfabric 202 and may be comprised of one or more buses, such as a systembus or an input/output bus. Of course, the bus system may be implementedusing any suitable type of architecture that provides for a transfer ofdata between different components or devices attached to the bus system.Additionally, a communications unit may include one or more devices usedto transmit and receive data, such as a modem or a network adapter.Further, a memory may be, for example, memory 206 or a cache such asfound in an interface and memory controller hub that may be present incommunications fabric 202.

Computer program code for carrying out operations of the presentinvention may be written in any combination of one or more programminglanguages, including an object-oriented programming language such asJava™, Smalltalk, C++, C#, Objective-C, or the like, and conventionalprocedural programming languages. The program code may execute entirelyon the user's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer, or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Those of ordinary skill in the art will appreciate that the hardware inFIGS. 1-2 may vary depending on the implementation. Other internalhardware or peripheral devices, such as flash memory, equivalentnon-volatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIGS. 1-2. Also, theprocesses of the illustrative embodiments may be applied to amultiprocessor data processing system, other than the SMP systemmentioned previously, without departing from the spirit and scope of thedisclosed subject matter.

As will be seen, the techniques described herein may operate inconjunction within the standard client-server paradigm such asillustrated in FIG. 1 in which client machines communicate with anInternet-accessible Web-based portal executing on a set of one or moremachines. End users operate Internet-connectable devices (e.g., desktopcomputers, notebook computers, Internet-enabled mobile devices, or thelike) that are capable of accessing and interacting with the portal.Typically, each client or server machine is a data processing systemsuch as illustrated in FIG. 2 comprising hardware and software, andthese entities communicate with one another over a network, such as theInternet, an intranet, an extranet, a private network, or any othercommunications medium or link. A data processing system typicallyincludes one or more processors, an operating system, one or moreapplications, and one or more utilities. The applications on the dataprocessing system provide native support for Web services including,without limitation, support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL,among others. Information regarding SOAP, WSDL, UDDI and WSFL isavailable from the World Wide Web Consortium (W3C), which is responsiblefor developing and maintaining these standards; further informationregarding HTTP and XML is available from Internet Engineering Task Force(IETF). Familiarity with these standards is presumed.

Network-Connected, Non-Display Secure Appliances

The secure nature of the physical appliance (sometimes referred toherein as a box) typically is provided by a self-disabling switch, whichis triggered if the appliance cover is removed. This physical securityenables the appliance to serve as a secure vault for sensitiveinformation. Typically, the appliance is manufactured, pre-loaded withsoftware, and then deployed within or in association with an enterpriseor other network operating environment; alternatively, the box may bepositioned locally and then provisioned with standard or customizedmiddleware virtual images that can be securely deployed and managed,e.g., within private or on-premise cloud computing environments. Theappliance may include hardware and firmware cryptographic support,possibly to encrypt data on hard disk. No users, includingadministrative users, can access any data on physical disk. Inparticular, preferably the operating system (e.g., Linux) locks down theroot account and does not provide a command shell, and the user does nothave file system access. Typically, the appliance does not include adisplay device, a CD or other optical drive, or any USB, Firewire orother ports to enable devices to be connected thereto. It is designed tobe a sealed and secure environment with limited accessibility and thenonly be authenticated and authorized individuals.

Referring to FIG. 3, a representative operating environment includes thephysical appliance 300, which interfaces to a network 302. The appliancemay be implemented using a data processing system such as describedabove with respect to FIG. 2. Preferably, the appliance 300 includes aWeb 2.0-based user interface (UI), a command line interface (CLI), andREST-based application programming interfaces (APIs). In this example,the appliance has been provisioned with an image comprising an operatingsystem 304, an application server 306, an HTTP server 308, and otherapplication programs 310. Additional software solutions (not shown) maybe included within the image. These software elements may comepre-loaded on the appliance, which may include other data (e.g.,templates, scripts, files, etc.). The particular software configurationof course will depend on the use being made of the appliance. Theappliance includes one of more storage devices (e.g., disk 315). Thetype and number of storage devices may vary.

The appliance also includes a button 305, such as a system reset.According to this disclosure, the appliance's normal system resetfunctionality is augmented to include a “multi-factor” decommissioningfunctionality, which is illustrated as a software-based component 312.As will be described, this functionality selectively controls theappliance so that it may be placed in a mode by which a user at a remotesystem 314 may “wipe” the storage device 315. This process is nowdescribed.

Multi-Factor Secure Appliance Decommissioning

Without limitation, the subject matter may be implemented in anynetwork-connected secure appliance irrespective of how that appliance isbeing used (e.g., SOA-support, network security, cloud applicationdeployment, etc.).

In general, a network-based appliance includes a mechanism to enablesecure erasure of sensitive data on the appliance's local storage,preferably prior to decommissioning. In one embodiment, the appliance'snormal system reset operation is augmented (or overridden) toselectively enable a local user to place the appliance into an operating(or “safe”) mode during which remote erasure of the local storage ispermitted, provided that mode is entered within a first time periodfollowing initiation of a system reset. If the appliance is placed inthe mode within the first time period, it can then receive appropriatecommands to wipe the local storage. Thus, once the safe mode is enteredby detecting one or more actions of a local user, preferably theappliance data itself is wiped by another person or entity that isremote from the device. Typically, the person is a remote privilegedadministrator that is assumed to have the authority and capability toformally “wipe” the appliance, but only while the appliance has beenfirst placed into the safe mode. Thus, preferably physical (local)presence to the appliance is necessary to place the device in the safemode, while non-physical (remote) presence with respect to the applianceis the state during which actually wiping of the storage device occurs.This implements a “multi-factor” decommissioning operation, namely, alocal operation (typically by a first person or entity) to place theappliance in the proper safe mode, with a remote operation (typically bya second person or entity) then being initiated to perform the erasureitself.

Preferably, the approach described herein is to create a button-based“wipe command” that can be carried out through standard appliancemanagement. Preferably, and with reference to FIG. 3, this is achievedby including the button 305 on the appliance (or to use an existingbutton whose function has been modified hereby) to place the applianceinto a state, but only for a limited time period, that allows itsinternal drive 315 to be wiped. As used herein, a “wipe” (or “erasure”)is assumed to erase all of the writeable file systems within theappliance directly, or to cause a boot of a dedicated kernel (not shown)that itself wipes those file systems. A state in which the appliance'sdata can be erased is sometimes referred to herein as a “safe mode.”Because the button 305 puts the appliance into the state that is enabledfor wipe, it may also be considered a “wipe/safe mode-enabled” button.This nomenclature is not intended to be limiting. The button 305 usedfor secure decommissioning according to this disclosure can be a buttondedicated to this function or simply the existing system reset (orother) appliance button whose operation is modified according to thetechniques herein. A physical button is not a requirement either, as thetechnique may be used with any physical switch, e.g., a knob, aselector, etc.

FIG. 4 is a process flow that illustrates how a special sequencing isapplied to the button to initiate the secure appliance decommissioningoperation of this disclosure. This is a local action. To this end, thebutton sequence preferably includes three (3) ordered stages as follows:stage 1 (402), which is a full system reset or safe mode entry; stage 2(404), a pre-safe mode entry; and stage 3 (404), safe mode entry. Thewipe occurs in stage 3. Stage 2 is an intermediary stage with theability either to go back to stage 1 (in an abort), or to proceed tostage 3. To enter safe mode, preferably the button 305 is asserted(held) for a given time (e.g., 3-5 seconds) allowing the device to starta full system reset (which is a conventional operation, and whichtypically is indicated by a beep). According to this disclosure,however, this operation is modified to initiate a watchdog timer thatfunctions in effect to inhibit the system reset while it is countingdown. The timer is implemented within the multi-factor functionality 312in FIG. 3. The timer starts counting down (upon initiation of the fullsystem reset) for a given first time period (e.g., 60 seconds, whichtime is configurable). The watching timer gates a full system reset fromoccurring until it has finally counted down. If safe mode is entered atany point during the first time period, the timer does not fully countdown and a system reset does not occur. To this end, preferably the usertakes another given action, such as pressing the button an additionalnumber of times (e.g., twice), to enter the safe mode (stage 3); if theuser only presses the button a single time, however, the system returns(from stage 2) back to stage 1. Preferably, a beep indicates asuccessful transition (from stage 1→stage 2→stage 3) to the safe modeafter each step. The watching timer is interrupted from fully countingdown by receipt of both interrupts at each assertion of the button.

Thus, safe mode is entered by detection of a local action on theappliance itself. Once in safe mode (stage 3), the watchdog timer resetsitself to a second time period and starts counting down again.Typically, the second time period is longer than the first time period.For example, the second time period (which itself preferably isconfigurable) is ten (10) minutes, although any period may be used. If,during the safe mode of operation, the watching timer then counts downand expires, i.e., the timer is not again interrupted, the appliance isfinally reset. Thus, upon initial system reset, the watchdog timerbegins a first (e.g., 1 minute) countdown; system reset is inhibitedduring the first time period to enable the user to enter the safe mode.If safe mode is entered, the watchdog timer begins a second (e.g., 10minute) countdown. The watchdog timer preferably is implemented insoftware and may be two (2) separate timers.

As noted, the button operations described above are a “local” actionbecause they take place (if at all) at the device itself. Once safe modeis entered, preferably the appliance data itself is wiped by anotherperson or entity that is remote from the device. This is a remoteaction. Typically, the person is a remote privileged administrator. Theremote privileged administrator may be a human being, or a computingentity controlled or managed by such a person. The remote administratoris assumed to have the authority and capability to formally “wipe” or“erase” the appliance, but only while the appliance has been placed intothe safe mode in the manner previously described. Thus, physical (local)presence to the appliance is necessary to place the device in safe mode,while non-physical (remote) presence with respect to the appliance isthe state during which actually wiping of the storage device occurs.Thus, a “multi-factor” decommissioning operation (one, a local operationto place the appliance in the proper safe mode, the other remote toperform the erasure) provides significant advantages.

The second or remote operation (or set of operations) is now described.These operations comprise an authorized remote request to erase at leastone storage device within the secure appliance, thereby wiping all datafrom that storage device. There may be multiple storage devices withinthe appliance, and the authorized remote request may serve to wipe all(or some) of these storage devices. There may be an authorized remoterequest to erase for each storage device within the appliance.Preferably, a single (global) request to wipe all storage devices isused.

When safe mode is entered, preferably the authorized remote requestitself is enabled in phases. First, preferably the remote user mustenter a first code corresponding to a hardware-based key on theappliance. For example, when the appliance is manufactured, a storagecontroller (or other) chip on the device may be programmed via an ECID(Electronic Chip Identification) fuse blown pattern. The hardware keywould then be known only to the manufacturer and purchaser of the chip(and the appliance). If the remote user can enter the first code, amatch on the hardware key then allows that user to take a secondrequired action, e.g., entry of a particular command that enables a bitin a hardware register so that the actual wipe mechanism can function.Once the second action (and there may be other requirements) completes,the remote user can finally enter a pre-programmed software code toperform the actual storage device wipe. While the pre-programmedsoftware code might be more publicly-known (and thus less secure),presumably the hardware keys and bit setting operation are much lesspublicly-known (and thus very secure). Together, these operations (or atleast some of them) comprise the authorized remote request. After thepre-programmed software code is received, an interrupt is sent to thewatchdog time, once again freezing the countdown. This allows the wipeto taken place. Once the wipe is finished, preferably the countdown isresumed (e.g., by another interrupt) and the system eventually resets.

FIG. 5 is a process flow representing the overall multi-factor operationin one embodiment. The routine begins at step 500 when the button isdepressed by a user local to the appliance. This initiates the watchdogtimer, which begins a first countdown (lasting for the first timeperiod). A test is then performed at step 502 to determine whether thetimer has expired. If so, the system resets at step 504. If the outcomeof the test at step 502 indicates that the watchdog timer has notexpired (and thus has been interrupted), a test is then performed atstep 506 to determine whether the local user has placed the applianceback into its pre-reset state (by moving back to stage 1). If theoutcome of the test at step 506 is negative, then the local user hastransitioned to stage 3, which is the safe mode. At step 508, thewatchdog timer is reset and begins a second countdown (lasting for thesecond time period). A test is then performed at step 510 to determinewhether the watchdog timer has expired. If so, control is returned tostep 504 and the system resets. If, however, the outcome of the test atstep 510 indicates that the watchdog timer has not expired (and onceagain has been interrupted), the routine continues. At step 512, a testis performed to determine whether the system can detect remote userinput of a hardware key assigned to some hardware element in theappliance. If the outcome of the test at step 512 is positive, theroutine then performs a test at step 514 to determine whether the systemcan detect remote user input of a software code assigned to theappliance. If and only if the outcome of the test at step 514 is thenpositive, the system is then placed in an operating mode by which it canreceive remote entry of a wipe command. If the outcome of either test512 or test 514 fails, the second countdown is re-started. Uponpermitted receipt of the wipe command, the local disk (or other datastore) is erased at step 516 to complete the process.

The above-described subject matter provides many advantages. Byrequiring a multi-factor operation as described, interested entities canbe assured that the sensitive data on the appliance (whether storedencrypted or in the clear) is securely wiped from the appliance prior toor in connection with decommissioning. The approach ensures that only anappropriate person or entity can perform the actual wipe, but therequirement of the local action (to initiate) the overall processensures against accidental or malicious wipes from even a privilegedremote administrator. The approach is safe, reliable, and simple toimplement in association with existing device reset functions.

There is no requirement that the multi-factor functionality beimplemented from a system reset, although this is a preferred operation.The functionality may be implemented as a standalone operation with itsown dedicated button. As noted, the particular local activationmechanism itself may be quite varied and is not limited to a physicalbutton.

While a preferred operating environment and use case (a secureappliance) has been described, the techniques herein may be used in anyother operating environment in which it is desired to decommission (orotherwise remove from service) a computing system or device and forwhich it is desired to ensure protection of the data that might bestored thereon.

As has been described, the functionality described above may beimplemented as a standalone approach, e.g., a software-based functionexecuted by a processor, or it may be available as a service (includingas a web service via a SOAP/XML interface). The particular hardware andsoftware implementation details described herein are merely forillustrative purposes are not meant to limit the scope of the describedsubject matter.

More generally, computing devices within the context of the disclosedsubject matter are each a data processing system (such as shown in FIG.2) comprising hardware and software, and these entities communicate withone another over a network, such as the Internet, an intranet, anextranet, a private network, or any other communications medium or link.The applications on the data processing system provide native supportfor Web and other known services and protocols including, withoutlimitation, support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, andWSFL, among others. Information regarding SOAP, WSDL, UDDI and WSFL isavailable from the World Wide Web Consortium (W3C), which is responsiblefor developing and maintaining these standards; further informationregarding HTTP, FTP, SMTP and XML is available from Internet EngineeringTask Force (IETF). Familiarity with these known standards and protocolsis presumed.

As explained, the scheme described herein may be implemented in or inconjunction with various server-side architectures including simplen-tier architectures, web portals, federated systems, and the like. Thetechniques herein may be practiced in a loosely-coupled server(including a “cloud”-based) environment.

Still more generally, the subject matter described herein can take theform of an entirely hardware embodiment, an entirely software embodimentor an embodiment containing both hardware and software elements. In apreferred embodiment, the trusted platform module function isimplemented in software, which includes but is not limited to firmware,resident software, microcode, and the like. Furthermore, the downloadand delete interfaces and functionality can take the form of a computerprogram product accessible from a computer-usable or computer-readablemedium providing program code for use by or in connection with acomputer or any instruction execution system. For the purposes of thisdescription, a computer-usable or computer readable medium can be anyapparatus that can contain or store the program for use by or inconnection with the instruction execution system, apparatus, or device.The medium can be an electronic, magnetic, optical, electromagnetic,infrared, or a semiconductor system (or apparatus or device). Examplesof a computer-readable medium include a semiconductor or solid statememory, magnetic tape, a removable computer diskette, a random accessmemory (RAM), a read-only memory (ROM), a rigid magnetic disk and anoptical disk. Current examples of optical disks include compactdisk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) andDVD. The computer-readable medium is a tangible, non-transitory item.

The computer program product may be a product having programinstructions (or program code) to implement one or more of the describedfunctions. Those instructions or code may be stored in a non-transitorycomputer readable storage medium in a data processing system after beingdownloaded over a network from a remote data processing system. Or,those instructions or code may be stored in a computer readable storagemedium in a server data processing system and adapted to be downloadedover a network to a remote data processing system for use in a computerreadable storage medium within the remote system.

In a representative embodiment, the interfaces and utility areimplemented in a special purpose computing platform, preferably insoftware executed by one or more processors. The software is maintainedin one or more data stores or memories associated with the one or moreprocessors, and the software may be implemented as one or more computerprograms. Collectively, this special-purpose hardware and softwarecomprises the functionality described above.

In the preferred embodiment, the functionality provided herein isimplemented as an adjunct or extension to an existing cloud computedeployment management solution.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

Finally, while given components of the system have been describedseparately, one of ordinary skill will appreciate that some of thefunctions may be combined or shared in given instructions, programsequences, code portions, and the like.

While the technique herein is described in the context of adecommissioning operation, this is not a limitation, as the techniquesmay be used whenever it is necessary or desirable to wipe an appliancedata store.

The appliance is not limited to any particular type of appliance. Themulti-factor operation may likewise be used to erase data from anymachine, irrespective of the machine's physical configuration.

The technique herein may be extended (beyond the “wipe” use case) toinvoke any privileged operation (by way of a privileged command). As oneof ordinary skill will appreciate, a goal of the described method is toidentify correctly the appliance to be operated upon using both physicaland remote pathways, so that the privileged operation (initiated by theprivileged command) cannot be invoked accidentally or maliciously eitherby the remote operator or the physical operator acting independently. Inaddition to the “wipe” privileged command, other privileged commandsincluding, without limitation, as “modify firmware” or “replaceoperating system,” etc., may use the approach. Thus, and generalizing,the multifactor security approach of this disclosure may be applied toinvoke any privileged operation (using a privileged command) where, byvirtue of its function, the privileged operation might present asecurity risk or otherwise be dangerous to the integrity of theappliance.

Having described our invention, what we now claim is as follows.

1. A method to invoke a privileged operation within a network-connectedappliance using a privileged command, comprising: responsive todetecting, during a first time period, of a local action on theappliance, initiating a second time period and transitioning theappliance into a state in which invocation of the privileged operationis allowed; and responsive to detecting, prior to expiration of thesecond time period, of an authorized remote request, initiating theprivileged command; wherein the operations are carried out by softwareexecuting in a hardware element in the device.
 2. The method asdescribed in claim 1 wherein the privileged command is a wipe command tosecurely erase storage device in the network-connected appliance.
 3. Themethod as described in claim 1 wherein the local action is receipt of abutton press on the appliance.
 4. The method as described in claim 1wherein the first time period is initiated upon detecting a system resetcommand.
 5. The method as described in claim 1 wherein detecting theauthorized remote request includes: detecting remote entry of a keyuniquely assigned to a hardware element in the device and responsive todetection of the remote entry of the key, interrupting the second timeperiod to allow initiating the privileged command.
 6. The method asdescribed in claim 5 further including: detecting remote entry of a codeuniquely assigned to a software element in the device prior tointerrupting the second time period.
 7. The method as described in claim6 wherein the privileged operation is initiated upon receipt of aprivileged command following detecting of remote entry of the key andthe code.
 8. The method as described in claim 1 further includinginitiating a system reset upon expiration of the first time period orthe second time period.